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Scope 



The present document defines a specification applicable to the Rr interface between Generic Resource Admission 
Control Function (x-RACF) instances, based on the Diameter protocol. Other alternative protocols which may also be 
used for this interface such as ANCP are not specified in the present document. 

Whenever it is possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of Diameter. Where this is not possible, extensions to Diameter are defined 
within the present document. 

2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 282 001 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); NGN Functional Architecture". 

[2] ETSI ES 282 003 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): 
Functional Architecture". 

[3] ETSI ES 282 004 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub- 
System (NASS)". 

[4] ETSI ES 283 034 (V2.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e4 interface 
based on the DIAMETER protocol". 

[5] ETSI TS 183 017 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN);Resource and Admission Control: DIAMETER protocol for 
session based policy set-up information exchange between the Application Function (AF) and the 
Service Policy Decision Function (SPDF); Protocol specification". 

[6] IETF RFC 4006: "Diameter Credit-Control AppUcation" . 
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[7] ETSI TS 129 209: "Universal Mobile Telecommunications System (UMTS); Policy control over 

Gq interface (3GPP TS 29.209)". 

[8] IETF RFC 3588: "Diameter Base Protocol". 

[9] IETF RFC 4005: "Diameter Network Access Server Application". 

[10] ETSI TS 183 026 (V3.y.z): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Resource and Admission Control; Protocol for QoS 
reservation information exchange between the Service Policy Decision Function (SPDF) and the 
Access Resource and Admission Control Function (A-RACF) In the Resource and Protocol 
specification". 

[11] ETSI TS 133 210: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; 3G security; Network Domain Security (NDS); IP 
network layer security (3GPP TS 33.210 )". 

[12] IETF RFC 4960: "Stream Control Transmission Protocol". 

[13] ETSI TS 129 207: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Policy control over Go interface (3GPP TS 29.207)". 

[14] IETF RFC 3554: "On the Use of Stream Control Transmission Protocol (SCTP) with IPSec". 

[15] ETSI TS 129 329: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Sh interface based on the Diameter protocol; Protocol 
details (3GPP TS 29.329)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

delegated x-RACF: x-RACF instance which works in the Rr delegated Model and performs admission control for the 
resources delegated by the delegating x-RACF 

delegating x-RACF: x-RACF instance which works in the Rr delegated Model and delegates a bulk of resources to 
another x-RACF instance for admission control 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAA AA-Answer 

AAR AA-Request 

ABNF Augmented Backus-Naur Form 

AF Application Function 

ANCP Access Node Control Protocol 

ASA Abort-Session-Answer 

ASR Abort-Session-Request 
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ATM Asynchronous Transfer Mode 

AVP Attribute-Value Pair 

CCA CC-Answer 

CCR CC-Request 

CEA Capabilities-Exchange-Answer 

CER Capabilities-Exchange-Request 

DHCP Dynamic Host Configuration Protocol 

FQDN Fully Qualified Domain Name 

lANA Internet Assigned Numbers Authority 

ID IDentifier 

IETF Internet Engineering Task Force 

IP Internet Protocol 

IPSec IP Security 

NASREQ Network Access Server Application 

NASS Network Attachment Sub-System 

PNA Push-Notification-Answer 

PNR Push-Notification-Request 

QoS Quality of Service 

RAA Re-Auth-Answer 

RACS Resource and Admission Control Sub-System 

RAR Re-Auth-Request 

RCEF Resource Control Enforcement Function 

RFC Request For Comments 

Rr reference point Rr 

RTCP Realtime Transport Control Protocol 

SCTP Stream Control Transport Protocol 

SDI Session Description Information 

SPDF Service-based Policy Decision Function 

STA Session-Termination-Answer 

STR Session-Termination-Request 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

UDA User-Data-Answer 

UDR User-Data-Request 

UE User Equipment 

VC Virtual Channel 

VP Virtual Path 

x-RACF Generic Resource Admission Control Function 
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Overview 



The present document specifies the Diameter protocol for the RACS Rr interface. The Rr interface is used for QoS 
resource reservation between x-RACF instances of RACS within a single administrative domain. The functional 
requirements and the stage 2 specifications of the Rr interface are contained in ES 282 001 [1] and ES 282 003 [2]. 




Figure 4.1 : Rr interface 



Procedure descriptions 



5.1 



General 



5.1.1 



Information elements 



The following clauses describe the realization of the functional procedures defined in the RACS (ES 282 003 [2]) using 
Diameter commands described in clauses 6 and 7. This involves describing a mapping between the Information 
Elements defined in the RACS specification (ES 282 003 [2]) and Diameter AVPs. 

In the tables that describe this mapping, each Information Element is marked as (M) Mandatory, (C) Conditional or (O) 
Optional: 

• A mandatory Information Element (marked as (M) in the table) shall always be present in the command. If this 
Information Element is absent, an application error occurs at the receiver and an answer message shall be sent 
back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message 
shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding 
Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element. 

• A conditional Information Element (marked as (C) in the table) shall be present in the command if certain 
conditions are fulfilled: 

If the receiver detects that those conditions are fulfilled and the Information Element is absent, an 
application error occurs and an answer message shall be sent back to the originator of the request with 
the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP 
AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the 
AVP Code and the other fields set as expected for this Information Element. If multiple Information 
Elements are missing, all corresponding AVP codes shall be included in the Failed-AVP AVP. 
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If those conditions are not fulfilled, the Information Element shall be absent. If however this Information 
Element appears in the message, it shall not cause an application error and it may be ignored by the 
receiver if this is not explicitly defined as an error case. Otherwise, an application error occurs at the 
receiver and an answer message with the Result-Code set to DIAMETER_AVP_NOT_ALLOWED shall 
be sent back to the originator of the request. A Failed- A VP AVP containing a copy of the corresponding 
Diameter AVP shall be included in this message. 

An optional Information Element (marked as (O) in the table) may be present or absent in the command, at the 
discretion of the application at the sending entity. Absence or presence of this Information Element shall not 
cause an application error and may be ignored by the receiver. 

5.2 Procedures on the Rr interface 

5.2.1 Resource control procecJures for Request Model 

The resource control process supports the following operations: 

1) Resource Reservation: the resources are admitted by the requested entity (e.g. lower-tier x-RACF). In relation 
to the enforcement operations performed in the co-located RCEF, it can be divided into the following 
categories: 

Reservation only: the resources are reserved but not allocated. 

Commit only: the pre-reserved resources are allocated. 

Reservation and commit: the resources are reserved and allocated. 

2) Resource Modification: the pre-reserved/committed resources are updated upon the request of the originating 
entity (e.g. top-tier x-RACF). 

3) Resource Release: the pre-reserved/committed resources are terminated upon the request of the originating 
entity. 

4) Event notification: a specific action is requested when a pre-defined event occurs (e.g. reservation expiration). 

The Flow-Status AVP is used to define the action to be taken for each AA -Request made by the top-tier x-RACF to the 
lower-tier x-RACF. The rules for interpreting the Flow-Status AVP are the following: 

• Resource Reservation: can be invoked by any of the following status: 

Reservation only: New Media-Description-Component AVP(s) and optionally Media-Sub-Component 
AVP(s) with Flow-Status AVP(s) set to DISABLED (3). 

Commit only: Media-Description-Component AVP(s) and optionally Media-Sub-Component AVP(s) of 
existing reservations with Flow-Status AVP(s) set to ENABLED-UPLINK (0), 
ENABLED-DOWNLINK (1) or ENABLED (2). 

ReservationAndCommit: New Media-Component-Description AVP(s) and optionally 
Media-Sub-Component AVP(s). Flow-Status AVP(s) set to ENABLED-UPLINK (0), 
ENABLED-DOWNLINK (1) or ENABLED (2). 

NOTE: For the purpose of the resource admission and reservation, any of above status triggers the procedure. The 
distinction of above flow status is only meaningful in the case the lower-tier x-RACF needs to control the 
enforcement operations (e.g. Opening the gate) in the co-located RCEF. 

• Resource Modification: Updated Media-Description-Component AVP(s) and Media-Sub-Component AVP(s). 
Flow-Status AVP not modified, unless the state needs to be modified (e.g. for committing a resource 
reservation, or for releasing a resource reservation). 

• Resource Release: Media-Description-Component AVP(s) and optionally Media-Sub-Component AVP(s) of 
existing reservations with Flow-Status AVP(s) set to REMOVED (4). 
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These resource control operations are described in the following clauses. During the operations Diameter AVPs are 
passed between the top-tier x-RACF and the lower-tier x-RACF. 



5.2.1.1 



Procedures at the Top-tier x-RACF 



5.2.1.1.1 



Resource Reservation Session Establishment and Initial Resource Reservation 



Upon the receipt of a new request from the SPDF, the top-tier x-RACF sends an initial request to the lower-tier x-RACF 
for initiating a resource reservation session. The AA-Request issued to request an initial reservation contains a new 
Session-Id assigned by the top-tier x-RACF. As specified in RFC 3588 [8], the Session-Id is globally unique and is 
meant to uniquely identify a resource session without reference to any other information. The Session-Id begins with 
the sender's identity encoded in the Diameterldentity type. 

This AA-Request message contains one or more Media-Component-Description Attribute-Value Pair(s) (AVP(s)). Each 
Media-Component-Description AVP describes the set of flows of a particular media type (i.e. it may contain one or 
more Media-Sub-Component AVP(s) and requirements for the flows). 

The top-tier x-RACF may forward an AF-Charging-Identifier AVP from the SPDF in the message for charging 
correlation purposes between AF and RACS. 

The resource admission and reservation operation that shall be performed by the lower-tier x-RACF for each individual 
media and flow is triggered by the following value of the Flow-Status AVP, as indicated in table 5.1: 

• Reservation; the value of the Flow-Status AVP shall be set to DISABLED (3). 

• ReservationAndCommit; the value of the Flow-Status AVP shall be set to ENABLED-UPLINK (0), 
ENABLED-DOWNLINK (1) or ENABLED (2). 

• The Flow-Status AVP shall be specified in the Media-Component-Description AVP and in the 
Media-Sub-Component AVP(s). The Flow-Status AVP shall be set to the same value in both these AVPs. 

Table 5.1 : Initial Reservation operations 



Message 
Type 


Flow-Status AVP at the level of 


Meaning 


Media 


Sub-Media 


AAR 


New Media, 
DISABLED 


New flow, 
DISABLED 


Reserve Resources for all the flows in the request. The media(s) 
and flow(s) descriptions MUST be new ones. 


AAR 


[New Media, 
ENABLE*] 


New flow, 
ENABLE* 


Reserve Resources. In addition, instruct the co-located RCEF to 
commit resources for some of the flows. The media(s) and 
flow(s) descriptions MUST be new ones (see note). 


NOTE: The control of committing resources in the co-located RCEF is an implementation choice and out of 
scope in the present document. 



As specified in clause 8.9 of RFC 3588 [8], the top-tier x-RACF may specify the Authorization-Lifetime AVP in the 
AA-Request to request a maximum lifetime for a session. To request a hard-state session the top-tier x-RACF shall omit 
the Authorization-Lifetime AVP in the AA-Request. To request a soft-state session the top-tier x-RACF shall specify 
this AVP in the AA-Request. 

The AA-Answer may contain the Authorization-Lifetime AVP. The AA-Answer may contain the Auth-Grace-Period 
AVP in addition to the Authorization-Lifetime AVP. The Authorization-Lifetime AVP specifies the maximum number 
of seconds before the Session must be refreshed by the top-tier x-RACF. The Auth-Grace-Period AVP contains the 
number of seconds the lower-tier x-RACF will wait for a Refresh following the expiration of the Authorization- 
Lifetime AVP. 

Whether the Authorization-Lifetime AVP and Auth-Grace-Period need to be included in the AA-Answer is a local 
decision of the lower-tier x-RACF. This means that the top-tier x-RACF may be offered a soft-state reservation 
although it asked for hard-state or a hard-state reservation although it asked for soft-state. Should the top-tier x-RACF 
not accept what is offered by the lower-tier x-RACF it must explicitly release the resources through issuing another 
AAR command. 

The top-tier x-RACF may specify, in the Specific- Action AVP of the AA-Request through which the initial reservation 
request is made, the events of which it wants to be informed. The supported events are listed in clause 6.5.9. 
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The behaviour when the top-tier x-RACF does not receive an AA- Answer, or when it arrives after the internal timer 
waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, is outside the 
scope of the present document. 

5.2.1 .1 .2 Resource Modification and Release for Media Flows 

The top-tier x-RACF may modify an existing session by sending an AA-Request to the lower-tier x-RACF with zero or 
more updated Media-Component-Description AVP(s) and optional Media-Sub-Component AVP(s). The Session-Id 
shall be an existing one and refer to the session that is to be modified. The top-tier x-RACF may perform the following 
operations: 

Add a new flow within a media component by providing a new Media-Sub-Component AVP within the 
corresponding Media-Component-Description AVP. 

Add a new flow within a new media component by providing a new Media-Component-Description AVP. 

Modify a media component by updating the corresponding Media-Component-Description AVP (e.g. increase 
or decrease the allocated bandwidth). 

Modify a flow within a media component by updating the corresponding Media-Sub-Component AVP. 

Modify a media flow state from Reserved to Committed by providing a Flow-Status AVP of the corresponding 
Media-Component-Description AVP and/or Media-Sub-Component AVP(s). The Flow-Status AVP shall be 
set to one of the values ENABLED-UPLINK, ENABLED-DOWNLINK or ENABLED, according to the 
direction in which the resources are to be committed. This operation requires that the media and flows are in 
the Reserved state prior to the AA-Request. 

• Release a media component by providing the corresponding Media-Component-Description AVP with the 
Flow-Status AVP set to the value REMOVED. 

• Release a flow within a media by providing the corresponding Media-Sub-Component AVP with the 
Flow-Status AVP set to the value REMOVED. 

• Refresh a soft-state session by providing an AA-Request message containing the Session-Id of the session that 
is to be refreshed. The AA-Request may contain the Authorization-Lifetime AVP to request a maximum 
lifetime of the refreshed session. If this AVP is not included, the refresh message requests the lifetime to be 
extended by a default value. The AA-Request may contain Media-Component-Description AVP(s) and 
Media-Sub-Component AVP(s) (e.g. to modify media, flows and/or commit status). 

The Flow-Status AVP in the Media-Sub-Component AVP shall always be the same as the Flow-Status AVP in the 
Media-Component-Description AVP containing the Media-Sub-Component AVP. 

The top-tier x-RACF SHALL NOT use the RAA to modify the session service information. As an option, the top-tier 
x-RACF MAY send an AAR command following an RAA to update the session service information after the local 
RACE responds with the RAR. 
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Table 5.2: Modification operations 



Message Type 


Flow-Status AVP at the level of 


Meaning 


Media 


Sub-Media 


AAR 


Existing Media 


Existing Flow, Unchanged 
Flow-Status 


Modify a media. In addition, modify a flow 
according to the new parameters specified in 
the Media-Sub-Component AVP. The Media 
and Flow must exist (see notes 1 , 2 and 5). 


AAR 


Existing Media 


New flow. Same Flow-Status 
AVP as in the media, 
(see note 3) 


Modify a media. In addition, add a new flow 
in a media. The Flow must be new (see 
notes 3 and 5). 


AAR 


Existing Media 
(see note 4) 


REMOVED 


Modify a media. In addition, release an 
existing flow within an existing media. If the 
flow does not exist, the request shall be 
ignored by the lower-tier x-RACF (see 
notes 2 and 5). 


AAR 


Existing Media, 
Modified Flow-Status 
AVP = REMOVED 


Existing Flow, Flow-Status 
AVP = REMOVED 


Release the resources of the media. 


AAR 


Existing Media 


Existing Flow 


(see note 5). 


NOTE 1 : If the media is not an existing one, tlie AAR is interpreted as a reservation for a new media (clause 5.2.1 .1 ). 
NOTE 2: The parameters specified at flow-level (in the IVIedia-Sub-Component AVP(s)) take precedence over the 

parameters specified at media-level (in the updated Media-Component-Description AVP). 
NOTE 3: The Flow-Status AVP of a new flow within a media shall be the same as the Flow-Status of the media. 
NOTE 4: As the Modification operation is also used for the Commit operation, the Flow-Status AVP of the 

Media-Component-Description AVP may actually be modified. 
NOTE 5: In the case of a soft-state reservation, extend its lifetime. 



The behaviour when the top-tier x-RACF does not receive an AA- Answer, or when it arrives after the internal timer 
waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, is outside the 
scope of the present document. 



5.2.1.1.3 



Termination and Release of the Resources for a Resource Reservation Session 



The top-tier x-RACF may issue a Session-Termination-Request (STR) command to the lower-tier x-RACF when it 
decides to terminate a resource reservation session and release all the resources. The session termination may be 
triggered by the explicit request from the SPDF or the expiry of the session or the inactivity of applications based on 
network policy. This command releases all the resources associated with the session identified by the provided 
Session-Id AVP. 

Table 5.3: Resource release operations 



Message 
Type 


Flow-Status AVP at the level of 


Meaning 


Media 


Sub-Media 


STR 






Release a session: all the media(s) and flow(s) within 
that session are released. 



When receiving an Abort-Session-Request (ASR) message from the lower-tier x-RACF, the top-tier x-RACF shall - if 
the session involves the resources in other network segments - release those resources and inform the SPDF of that the 
resources identified by the Session-Id AVP have been released. If the ASR message contains one or more 
Session-Bundle-Id AVPs the top-tier x-RACF shall perform these procedures for all sessions associated with the 
Session-Bundle-Id AVP(s). 



5.2.1.1.4 



Event notification 



Notifications for specific events may be implicitly requested through policies established in the lower-tier x-RACF. The 
top-tier x-RACF may further specify, in the Specific-Action AVP of an initial AA-Request command, the events of 
which it wants to be informed. The supported events are listed in clause 6.5.9. 
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5.2.1.2 



Procedures at the lower-tier x-RACF 



5.2.1.2.1 



Initial Resource Reservation 



When the lower-tier x-RACF receives a reservation request in which the Session-Id is new, it is interpreted by the 
lower-tier x-RACF as a new resource reservation session. 

An initial AA-Request may contain one or more Media-Component-Description AVP(s) optionally including one or 
more Media-Sub-Component AVP(s). If the initial AA-Request does not contain any Media-Component-Description 
AVP(s), the lower-tier x-RACF will establish the Diameter session as the idle state without further operations. 

Upon reception of an AF- Application-Identifier AVP in an initial AA-Request from the top-tier x-RACF, the lower-tier 
x-RACF shall store this identifier together with the states created and maintained for the new session for the purpose of 
charging correlation between AF and RACS. The identifier is opaque to the lower-tier x-RACF. 

As defined in ES 282 003 [2], the top-tier x-RACF identifies a QoS profile based on the Subscriber ID and/or the 
Globally Unique IP Address. The QoS profile includes the Physical Access ID, Logical Access ID and Access Network 
Type. 

The lower-tier x-RACF does not interact with the NASS directly. Instead, the top-tier x-RACF maintains the QoS 
profiles, selects the right one and pushes the relevant information (e.g. QoS info) down to the lower-tier x-RACF. 

To identify a specific customer on the lower-tier x-RACF, the top-tier x-RACF shall convey the Logical Access ID, and 
optionally the Globally Unique IP Address. 

The mapping of these parameters to the Diameter AVPs is described in table 5.4. If the lower-tier x-RACF does not 
receive one of these parameters at least the Logical-Access-Id AVP, it shall return an AA-Answer that include a 
Result-Code AVP set to the value DIAMETER_MISSING_AVP. The Failed-AVP AVP should be included in the 
message. The Failed-AVP AVP must contain an example of the missing AVP. The value field of the missing AVP 
example should be of correct minimum length and contain zeroes. 

Table 5.4: Mapping of information element names to Diameter AVPs 



Information element name 


Mapping to Diameter AVP 


Categorie 


Logical Access ID (The identity of the logical 
access to which the user equipment is 
connected. See note) 


Logical-Access-ld 


M 


Subscriber ID in RACS [2] and in NASS [3] 


User-Name 





Globally Unique IP Address in RACS [2] and 
in NASS [3] 


Globally-Unique-Address 





Requestor Name in RACS [2] 


AF-Application-ldentifier 





Media Type in NASS [3] and in RACS [2] 


IVIed la-Type 





Reservation Class in RACS [2] 


Reservation-Class 





Transport Service Class in RACS [2] and in 
NASS [31 


Transport-Class 





Service Class in RACS [2] 


Service-Class 





NOTE: The Logical Access ID identifies the logical access used by the attached user 
equipment. In the xDSL case, the Logical Access ID may explicitly contain the 
identifier of VP and/or VC carrying the traffic. Can be used as the agent circuit ID 
present in DHCP option 82, including <Access-Node-ldentifier> atm 
<rack>/<shelf>/<slot>/<DSL-Line>:<VPI.<VCI>. 



Any value of the Flow-Status AVP received in an initial AA-Request (in which the Session-Id is new) different from 
ENABLED-UPLINK, ENABLED-DOWNLINK, ENABLED or DISABLED shall result in an error. If the Flow-Status 
AVP has the value REMOVED the lower-tier x-RACF shall return an AA-Answer containing a Failed-AVP AVP and a 
Result-Code AVP with the value DIAMETER_INVALID_AVP_VALUE. 

In case the operation fails due to lack of resources, the lower-tier x-RACF shall include the Experimental-Result-Code 
AVP set to the value INSUFFICIENT_RESOURCES. 

An initial reservation request can be admitted by the lower-tier x-RACF if for all media streams in the session, the 
resource requirements fit within the constraints of remaining envelopes of unused resources. The lower-tier x-RACF is 
presumed to exhibit "atomic" reservation semantics (i.e. either all reservations are admitted, or none of them). Once a 
reservation is admitted, the corresponding amount of resources is removed from the pool of available resources. 
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If the request is admitted the lower-tier x-RACF must send an AA- Answer back to the top-tier x-RACF and include the 
Resuh-Code AVP set to the value DIAMETER_SUCCESS. 

Upon successful reservation, the lower-tier x-RACF shall store the Diameter base protocol Session-Id received in the 
AA-Request through which the initial reservation request was made, and the Media-Component-Number(s) and 
Flow-Number(s). The AA-Request may contain the Authorization-Lifetime AVP. The lower-tier x-RACF shall 
interpret the presence of the Authorization-Lifetime AVP as a request for a soft-state reservation and the absence of this 
AVP as a request for a hard-state reservation. The lower-tier x-RACF may however return the Authorization-Lifetime 
AVP or the pair of Authorization-Lifetime AVP and Auth-Grace-Period AVP although the AA-Request did not contain 
the Authorization-Lifetime AVP. The lower-tier x-RACF thereby offers a soft-state reservation although the request 
was for hard-state. The lower-tier x-RACF may also choose not to return the Authorization-Lifetime AVP and the 
Auth-Grace-Period AVP although the AA-Request contained the Authorization-Lifetime AVP. The lower-tier x-RACF 
thereby offers a hard-state reservation although the request was for soft-state reservation. 

The Authorization-Lifetime indicates when the lower-tier x-RACF expects a Refresh from the top-tier x-RACF. The 
Auth-Grace-Period AVP can only be specified in addition to the Authorization-Lifetime AVP. 

As specified in clause 8.9 of RFC 3588 [8] the Diameter server (i.e. the lower-tier x-RACF) may return the 
Authorization-Lifetime AVP set to a value equal to, or smaller than the value of the Authorization-Lifetime AVP 
provided by the top-tier x-RACF. 

The lower-tier x-RACF may include one or more Session-Bundle-Id AVPs in the AA -Answer. The Session-Bundle-Id 
AVP identifies a group of sessions to which the session belongs. The value of this AVP and the sessions that belong to a 
certain such value are chosen by the lower-tier x-RACF. The value of the Session-Bundle-Id AVP is meaningful only 
for the lower-tier x-RACF. If the Specific- Action AVP is included in the initial AA-Request, notification for the given 
event(s) shall be activated by the lower-tier x-RACF. The supported events are listed in clause 6.5.8. 

5.2.1 .2.2 Resource Modification and Release for Media Flows 

When the lower-tier x-RACF receives requests in which both the Session-Id and the Media-Component-Number(s) and 
Flow-Number(s) of existing reservations are existing ones, it performs the resource admission and reservation for 
modified flows. 

An AA-Request issued to modify an existing session may contain zero or more Media-Component-Description AVP(s) 
optionally including one or more Media-Sub-Component AVP(s). Media-Component-Number(s) and Flow-Number(s) 
of new Media-Component-Description AVP(s) and Media-Sub-Component AVP(s) are interpreted by the lower-tier 
x-RACF as new ones. 

For an AA-Request issuing a session modification operation the Flow-Status AVP must be set to a value representing a 
state to which the session is allowed to enter from its current state. Should the Flow-Status AVP be set to a disallowed 
value the lower-tier x-RACF shall return an AA- Answer containing a Failed- AVP AVP and a Result-Code AVP with 
the value DIAMETER_INVALID_AVP_VALUE. 

In the case the lower-tier x-RACF also needs to control the enforcement of the resources, if the lower-tier x-RACF is 
unable to modify the status of a reservation to ENABLED-UPLINK, ENABLED -DOWNLINK or ENABLED, the 
lower-tier x-RACF shall issue an error message to the top-tier x-RACF with an Experimental-Result-Code AVP set to 
the value COMMIT_FAILURE. If the status of a reservation is one of the values ENABLED-UPLINK, 
ENABLED -DOWNLINK or ENABLED, the AA-Request should not contain a Flow-Status AVP set to DISABLED. If 
it does, the lower-tier x-RACF shall return an AA-Answer to the top-tier x-RACF with an Experimental-Result-Code 
AVP set to the value MODIFICATION_FAILURE. If the lower-tier x-RACF is not able to re-initiaUze the lifetime of 
the reservation, it shall return an AA-Answer to the top-tier x-RACF with an Experimental-Result-Code AVP set to the 
value REFRESH_FAILURE. 

If a flow-level operation fails, the entire Resource Modification operation fails. In the case the lower-tier x-RACF 
determines that the request cannot be admitted due to insufficient resources, it shall return an Experimental-Result-Code 
AVP to the top-tier x-RACF set to the value INSUFFICIENT_RESOURCES. 

In case the Specific- Action AVP, the AF-Charging-Identifier AVP, the User-Name AVP or the Globally-Unique- 
Address AVP was provided in an initial AA-Request with a value different from the value of the AVP(s) in a modifying 
AA-Request, the lower-tier x-RACF shall return an AA-Answer containing a Failed- AVP AVP and a Result-Code AVP 
with the value DIAMETER_INVALID_AVP_VALUE. 

Upon successful session modification, the lower-tier x-RACF must send an AA-Answer back to the top-tier x-RACF 
with the Result-Code AVP set to DIAMETER_SUCCESS. 
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Upon a successful refresh operation, the lower-tier x-RACF shall in the AA- Answer return the Authorization-Lifetime 
AVP with a value equal or smaller than the Authorization-Lifetime AVP of the AA-Request (if any). The 
Auth-Grace-Period AVP can only be specified in addition to the Authorization-Lifetime AVP. 

Whether Authorization-Lifetime AVP and Auth-Grace-Period AVP need to be specified in the AA- Answer is a local 
decision for the lower-tier x-RACF. 

If a reference to a previously negotiated Media-Component-Description AVP and/or Media-Sub-Component AVP for 
the session in question is omitted in the AA-Request, the corresponding flow is not impacted by the Modification 
operation. 

5.2.1 .2.3 Termination and Release of the Resources for a Resource Reservation Session 

If all resources within an established resource reservation session need to be terminated, the lower-tier x-RACF shall 
inform the top-tier x-RACF about this event by sending an Abort-Session-Request (ASR) message with the appropriate 
Abort-Cause AVP value, and all resources within the authorized session will be released. The lower-tier x-RACF may 
include one or more Session-Bundle-Id AVPs in order to inform the top-tier x-RACF of that several sessions identified 
by the provided Session-Bundle-Id AVP(s) are terminated. 

Upon receipt of a Session-Termination-Request (STR) message from the top-tier x-RACF the lower-tier x-RACF shall 
release all the resources associated with the session identified through the provided Session-Id AVP. If an unknown 
Session-Id is provided in the STR the lower-tier x-RACF shall return a Session-Termination- Answer (STA) message to 
the top-tier x-RACF with the Result-Code AVP set to DIAMETER_UNKNOWN_SESSION_ID. 

5.2.1.2.4 Event Notification 

If an event for which notification is required occurs, the lower-tier x-RACF shall send an unsolicited Re-Auth-Request 
(RAR) message to the top-tier x-RACF containing: 

• The value of the Specific- Action AVP, indicating the event that occurred. 

• Optionally, the appropriate Abort-Cause AVP value. 

5.2.2 Procedures for Delegated Model 

5.2.2.1 Delegation Push triggered by the delegating x-RACF 

This procedure is used for the delegating x-RACF to push the delegation information to the delegated x-RACF. This 
information flow occurs at the initial provisioning stage or when the delegating x-RACF decides to synchronize the 
delegation information between the delegating x-RACF and the delegated x-RACF. This procedure is mapped to the 
commands Push-Notification-Request/ Answer in the Diameter application specified in clause 7. 

5.2.2.1 .1 Procedures at the delegating x-RACF 

The delegating x-RACF shall obtain the address of the delegated x-RACF entity where the information should be 
pushed (e.g. from configuration data). 

The delegating x-RACF shall populate the Push-Notification-Request as follows: 

• The Network-Resource-Id AVP shall be present and shall contain the identifier of the network resource to be 
delegated. 

• At least one of Granted-Delegated-Bandwidth-UL and Granted-Delegated-Bandwidth-DL AVP shall be 
present. 

• The presence of Total-Bandwidth-UL and Total-Bandwidth-DL AVP depends on the network resource and 
local policy rules. 

The Preferred-Delegated-Bandwidth-UL, Preferred-Delegated-Bandwidth-DL, Required-Delegated-Bandwidth-UL, 
Required-Delegated-Bandwidth-DL and Reservation-priority AVPs shall not be present. 
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5.2.2.1 .2 Procedures at the delegated x-RACF 

On receipt of the Push-Notification-Request with at least either of the Granted-Delegated-Bandwidth-UL and 
Granted-Delegated-Bandwidth-DL AVPs, the delegated x-RACF take the Push-Notification-Request as the delegation 
push request. 

If there is no delegation record with the network resource identifier contained in the Network-Resource-Id AVP as a 
key, the delegated x-RACF shall create an internal record to store the received information for future use. 

If there is a delegation record with the network resource identifier contained in the Network-Resource-Id AVP as a key, 
the delegated x-RACF shall replace the entire content of the internal record with the received information for future use. 
Such an update shall not have any impact on ongoing application sessions for which an authorization has already been 
provided by the delegating x-RACF. 

If the contents of the request are invalid the delegated x-RACF shall return a Push-Notification- Answer with a 
Result-Code AVP value set to the appropriate value as described in clause 5.1. 

If the delegated x-RACF cannot fulfil the received request for reasons not stated in the above steps, e.g. due to database 
error, it shall stop processing the request and return a Push-Notification- Answer with a Result-Code AVP value set to 
DIAMETER_UNABLE_TO_COMPLY or an Experimental-Result-Code AVP set to 

DIAMETER_SYSTEM_UNAVAILABLE. In the later case, the delegating x-RACF is expected to retry after a 
provisioned time period. 

Otherwise, the requested operation shall take place and the delegated x-RACF shall return the Result-Code AVP set to 
DIAMETER_SUCCESS in the Push-Notification-Answer. 

The Granted-Delegated-Bandwidth-UL and Granted-Delegated-Bandwidth-DL should not be present in the 
Push-Notification- Answer. 

5.2.2.2 Delegation Negotiation triggered by the delegated x-RACF 

This procedure is used for the delegated x-RACF to negotiate the delegation with the delegating x-RACF. This 
information flow occurs normally when there is insufficient delegated bandwidth for a new application session on the 
delegated x-RACF. This procedure is mapped to the commands User-Data-Request/ Answer in the Diameter application 
specified in clause 7. 

5.2.2.2.1 Procedures at the delegated x-RACF 

The delegated x-RACF shall populate the User-Data-Request as follows: 

• The Network-Resource-Id AVP shall be present and shall contain the identifier of the network resource to be 
delegated. 

• At least one of the Required-Delegated-Bandwidth-UL and Required-Delegated-Bandwidth-DL AVP shall be 
present. 

• The Preferred-Delegated-Bandwidth-UL, Preferred-Delegated-Bandwidth-DL and Reservation-priority AVPs 
may be present optionally. If the Required-Delegated-Bandwidth-UL AVP is not present, the Preferred- 
Delegated-Bandwidth-UL AVP shall not be present. If the Required-Delegated-Bandwidth-DL AVP is not 
present, the Preferred-Delegated-Bandwidth-DL AVP shall not be present. 

On receipt of the corresponding User-Data- Answer with the Result-Code AVP set to DIAMETER_SUCCESS and at 
least either of the Granted-Delegated-Bandwidth-UL and Granted-Delegated-Bandwidth-DL AVPs, the delegated 
x-RACF updates the corresponding content of the internal record with the received information for future use 
(e.g. allocating the resource for pending application sessions). 

5.2.2.2.2 Procedures at the delegating x-RACF 

On receipt of the User-Data-Request with at least either of the Required-Delegated-Bandwidth-UL and Required- 
Delegated-Bandwidth-DL AVPs, the delegating x-RACF takes the User-Data-Request as the delegation negotiation 
request. 
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If the contents of the request are invalid the delegating x-RACF shall return a User-Data- Answer with a Result-Code 
AVP value set to the appropriate value as described in clause 5.1. 

The delegating x-RACF shall, in the following order: 

1) If the network resource identified by the Network-Resource-Id AVP is unknown or is not handled in the 
delegating x-RACF or is not allowed to be delegated to the delegated x-RACF, return a User-Data- Answer 
with the Experimental-Result-Code AVP set to NETWORK_RESOURCE_UNAVAILABLE. 

2) If the network resource identified by the Network-Resource-Id AVP is handled in the delegating x-RACF and 
is allowed to be delegated to the delegated x-RACF, decide if the delegated bandwidth can be changed to the 
value indicated by the messages for each requested direction. 

a) If Preferred-Delegated-Bandwidth-UL (Preferred-Delegated-Bandwidth-DL) AVP is present and the 
uplink (downlink) delegated bandwidth to be delegated can be changed to the amount carried in this 
AVP without affecting the ongoing application sessions admitted by the delegating x-RACF and 
violating any policy rules in the delegating x-RACF, the delegating x-RACF changes the uplink 
(downlink) delegated bandwidth to the amount carried in the Preferred-Delegated-Bandwidth-UL 
(Preferred-Delegated-Bandwidth-DL) AVP. 

b) If Preferred-Delegated-Bandwidth-UL (Preferred-Delegated-Bandwidth-DL) AVP is not present or the 
uplink (downlink) delegated bandwidth can not be changed to the value carried in the 
Preferred-Delegated-Bandwidth-UL (Preferred-Delegated-Bandwidth-DL) AVP without affecting the 
ongoing application sessions admitted by the delegating x-RACF and violating any policy rules in the 
delegating x-RACF, the delegating x-RACF decides if the uplink (downlink) delegated bandwidth can be 
changed to the value indicated by the Required-Delegated-Bandwidth-UL 
(Required-Delegated-Bandwidth-DL) AVP: 

i) If the uplink (downlink) delegated bandwidth can be changed to the value carried in the 

Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth-DL) AVP without affecting 
the ongoing application sessions admitted by the delegating x-RACF and violating any policy rules 
in the delegating x-RACF, the delegating x-RACF changes the uplink (downlink) delegated 
bandwidth to the amount carried in the Required-Delegated-Bandwidth-UL 
(Required-Delegated-Bandwidth-DL) AVP. 

ii) If the uplink (downlink) delegated bandwidth can not be changed to the value carried in the 

Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth-DL) AVP without affecting 
the ongoing application sessions admitted by the delegating x-RACF and violating any policy rules 
in the delegating x-RACF, and if the Reservation-priority AVP is present, the delegating x-RACF 
evaluates if the uplink (downlink) delegated bandwidth can reach the value carried in the 
Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth-DL) AVP by releasing 
sufficient ongoing application sessions with lower reservation priority than the value carried in the 
Reservation-priority AVP. If it can, then the delegating x-RACF releases sufficient ongoing 
application sessions with lower reservation priority, and changes the uplink (downlink) delegated 
bandwidth to the amount carried in the Required-Delegated-Bandwidth-UL 
(Required-Delegated-Bandwidth-DL) AVP. 

c) If either direction of the delegated bandwidth can not be changed as requested in the above steps, the 
delegating x-RACF shall return a User-Data- Answer with the Experimental-Result-Code AVP set to 
NETWORK_RESOURCE_INSUFFICIENT. Otherwise, the delegating x-RACF shall return a 
User-Data-Answer with the Result-Code AVP set to DIAMETER_SUCCESS and with the delegated 
bandwidth(s) in both or either of the Granted-Delegated-Bandwidth-UL and 
Granted-Delegated-Bandwidth-DL AVP. If the uplink delegated bandwidth is requested, the 
Granted-Delegated-Bandwidth-UL AVP must be included in the successful answer. If the downlink 
delegated bandwidth is requested, the Granted-Delegated-Bandwidth-DL AVP must be included in the 
successful answer. 

5.2.2.3 Delegation Negotiation triggered by the delegating x-RACF 

This procedure is used for the delegating x-RACF to negotiate the delegation with the delegated x-RACF. This 
information flow occurs normally when there is insufficient delegated bandwidth for a new application session on the 
delegating x-RACF. This procedure is mapped to the commands Push-Notification-Request/ Answer in the Diameter 
application specified in clause 7. 
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5.2.2.3.1 Procedures at the delegating x-RACF 

The delegating x-RACF shall populate the Push-Notification-Request as follows: 

• The Network-Resource-Id AVP shall be present and shall contain the identifier of the network resource to be 
delegated. 

• At least one of the Required-Delegated-Bandwidth-UL and Required-Delegated-Bandwidth-DL AVP shall be 
present. 

• The Preferred-Delegated-Bandwidth-UL, Preferred-Delegated-Bandwidth-DL and Reservation-priority AVPs 
may be present optionally. If the Required-Delegated-Bandwidth-UL AVP is not present, the Preferred- 
Delegated-Bandwidth-UL AVP shall not be present. If the Required-Delegated-Bandwidth-DL AVP is not 
present, the Preferred-Delegated-Bandwidth-DL AVP shall not be present. 

On receipt of the corresponding Push-Notification- Answer with the Result-Code AVP set to DIAMETER_SUCCESS 
and at least either of the Granted-Delegated-Bandwidth-UL and Granted-Delegated-Bandwidth-DL AVPs, the 
delegating x-RACF updates the corresponding content of the internal record with the received information for future 
use (e.g. allocating the resource for the pending application sessions). 

5.2.2.3.2 Procedures at the delegated x-RACF 

On receipt of the Push-Notification-Request with at least either of the Required-Delegated-Bandwidth-UL and 
Required-Delegated-Bandwidth-DL AVPs, the delegated x-RACF takes the Push-Notification-Request as the 
delegation negotiation request. 

If the contents of the request are invalid the delegated x-RACF shall return a Push-Notification- Answer with a 
Result-Code AVP value set to the appropriate value as described in clause 5.1. 

The delegated x-RACF shall, in the following order: 

1) If there is no delegation record with the network resource identifier contained in the Network- Resource-Id 
AVP as a key, return a Push-Notification- Answer with the Experimental-Result-Code AVP set to 
NETWORK_RESOURCE_UNAVAILABLE. 

2) If there is a delegation record with the network resource identifier contained in the Network-Resource-Id AVP 
as a key, decide if the delegated bandwidth can be changed to the value indicated by the messages for each 
requested direction. 

a) If Preferred-Delegated-Bandwidth-UL (Preferred-Delegated-Bandwidth-DL) AVP is present and the 
uplink (downlink) delegated bandwidth to be delegated can be changed to the amount carried in this 
AVP without affecting the ongoing application sessions admitted by the delegated x-RACF, the 
delegated x-RACF changes the uplink (downlink) delegated bandwidth to the amount carried in the 
Preferred-Delegated-Bandwidth-UL (Preferred-Delegated-Bandwidth-DL) AVP. 

b) If Preferred-Delegated-Bandwidth-UL (Preferred-Delegated-Bandwidth-DL) AVP is not present or the 
uplink (downlink) delegated bandwidth can not be changed to the value carried in the 
Preferred-Delegated-Bandwidth-UL (Preferred-Delegated-Bandwidth-DL) AVP without affecting the 
ongoing application sessions admitted by the delegated x-RACF, the delegated x-RACF decides if the 
uplink (downlink) delegated bandwidth can be changed to the value indicated by the 
Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth-DL) AVP: 

i) If the uplink (downlink) delegated bandwidth can be changed to the value carried in the 

Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth-DL) AVP without affecting 
the ongoing application sessions admitted by the delegated x-RACF, the delegated x-RACF 
changes the uplink (downlink) delegated bandwidth to the amount carried in the 
Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth-DL) AVP. 
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ii) If the uplink (downlink) delegated bandwidth can not be changed to the value carried in the 

Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth-DL) AVP without affecting 
the ongoing application sessions admitted by the delegated x-RACF, and if the Reservation-priority 
AVP is present, the delegated x-RACF evaluates if the uplink (downlink) delegated bandwidth can 
reach the value carried in the Required-Delegated-Bandwidth-UL (Required-Delegated-Bandwidth- 
DL) AVP by releasing sufficient ongoing application sessions with lower reservation priority than 
the value carried in the Reservation-priority AVP. If it can, then the delegated x-RACF releases 
sufficient ongoing application sessions with lower reservation priority, and changes the uplink 
(downlink) delegated bandwidth to the amount carried in the Required-Delegated-Bandwidth-UL 
(Required-Delegated-Bandwidth-DL) AVP. 

c) If either direction of the delegated bandwidth can not be changed as requested in the above steps, the 

delegated x-RACF shall return a Push-Notification- Answer with the Experimental-Result-Code AVP set 
to NETWORK_RESOURCE_INSUFFICIENT. Otherwise, the delegated x-RACF shall return a 
Push-Notification-Answer with the Result-Code AVP set to DIAMETER_SUCCESS and with the 
delegated bandwidth(s) in both or either of the Granted-Delegated-Bandwidth-UL and 
Granted-Delegated-Bandwidth-DL AVP. If the uplink delegated bandwidth is requested, the 
Granted-Delegated-Bandwidth-UL AVP must be included in the successful answer. If the downlink 
delegated bandwidth is requested, the Granted-Delegated-Bandwidth-DL AVP must be included in the 
successful answer. 

5.2.2.4 Delegation Query triggered by the delegating x-RACF 

This procedure is used for the delegating x-RACF to query the delegation from the delegated x-RACF. This information 
flow occurs normally when the delegating x-RACF discovers there is a possibility of inconsistency of the delegation 
between the delegating x-RACF and the delegated x-RACF. This procedure is mapped to the commands 
Push-Notification-Request/ Answer in the Diameter application specified in clause 7. 

5.2.2.4.1 Procedures at the delegating x-RACF 

The delegating x-RACF shall populate the Push-Notification-Request as follows: 

• The Network-Resource-Id AVP shall be present and shall contain the identifier of the network resource to be 
delegated. 

• None of the Granted-Delegated-Bandwidth-UL, Granted-Delegated-Bandwidth-DL, 
Preferred-Delegated-Bandwidth-UL, Preferred-Delegated-Bandwidth-DL, Required-Delegated- 
Bandwidth-UL, Required-Delegated-Bandwidth-DL and Reservation-priority AVPs shall be present. 

On receipt of the corresponding Push-Notification- Answer with the Result-Code AVP set to DIAMETER_SUCCESS 
and at least either of the Granted-Delegated-Bandwidth-UL and Granted-Delegated-Bandwidth-DL AVPs, the 
delegating x-RACF may take the result of the query into account in deciding whether synchronization is needed and 
how much bandwidth should be delegated. 

5.2.2.4.2 Procedures at the delegated x-RACF 

On receipt of the Push-Notification-Request with none of the Granted-Delegated-Bandwidth-UL, 
Granted-Delegated-B andwidth-DL, Preferred-Delegated-B andwidth-UL, Preferred-Delegated-B and width-DL, 
Required-Delegated-Bandwidth-UL, Required-Delegated-B andwidth-DL and Reservation-priority AVPs, the delegated 
x-RACF takes the Push-Notification-Request as the delegation query request. 

If the contents of the request are invalid the delegated x-RACF shall return a Push-Notification- Answer with a 
Result-Code AVP value set to the appropriate value as described in clause 5.1. 

The delegated x-RACF shall, in the following order: 

1) If there is no delegation record with the network resource identifier contained in the Network- Resource-Id 
AVP as a key, return a Push-Notification- Answer with the Experimental-Result-Code AVP set to 
NETWORK_RESOURCE_UNAVAILABLE. 
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2) If there is a delegation record with the network resource identifier contained in the Network-Resource-Id AVP 
as a key, return a Push-Notification-Answer with the Result-Code AVP set to DIAMETER_SUCCESS and 
populate the Push-Notification-Request as follows: 

a) The Granted-Delegated-Bandwidth-UL shall be present if the uplink bandwidth has been delegated to the 
delegated x-RACF. 

b) The Granted-Delegated-Bandwidth-DL shall be present if the downlink bandwidth has been delegated to 
the delegated x-RACF. 

c) The Total-Bandwidth-UL shall be present if the total uplink bandwidth has been provisioned by the 
delegating x-RACF. 

d) The Total-Bandwidth-DL shall be present if the total downlink bandwidth has been provisioned by the 
delegating x-RACF. 

5.2.2.5 Delegation Query triggered by the delegated x-RACF 

This procedure is used for the delegated x-RACF to query the delegation from the delegating x-RACF. This information 
flow occurs normally when the delegated x-RACF discovers there is a possibility of inconsistency of the delegation 
between the delegated x-RACF and the delegating x-RACF. This procedure is mapped to the commands 
User-Data-Request/ Answer in the Diameter application specified in clause 7. 

5.2.2.5.1 Procedures at the delegated x-RACF 

The delegated x-RACF shall populate the User-Data-Request as follows: 

• The Network-Resource-Id AVP shall be present and shall contain the identifier of the network resource to be 
delegated. 

• None of the Granted-Delegated-Bandwidth-UL, Granted-Delegated-Bandwidth-DL, Preferred-Delegated- 
Bandwidth-UL, Preferred-Delegated-Bandwidth-DL, Required-Delegated-Bandwidth-UL, Required- 
Delegated-Bandwidth-DL and Reservation-priority AVPs shall be present. 

On receipt of the corresponding User-Data- Answer with the Result-Code AVP set to DIAMETER_SUCCESS and at 
least either of the Granted-Delegated-Bandwidth-UL and Granted-Delegated-Bandwidth-DL AVPs, the delegated 
x-RACF updates the corresponding content of the internal record with the received information for future use 
(e.g. allocating the resource for new application sessions). 

5.2.2.5.2 Procedures at the delegating x-RACF 

On receipt of the User-Data-Request with none of the Granted-Delegated-Bandwidth-UL, 
Granted-Delegated-Bandwidth-DL, Preferred-Delegated-Bandwidth-UL, Preferred-Delegated-Bandwidth-DL, 
Required-Delegated-Bandwidth-UL, Required-Delegated-Bandwidth-DL and Reservation-priority AVPs, the 
delegating x-RACF takes the User-Data-Request as the delegation query request. 

If the contents of the request are invalid the delegating x-RACF shall return a User-Data- Answer with a Result-Code 
AVP value set to the appropriate value as described in clause 5.L 

The delegating x-RACF shall, in the following order: 

1) If the network resource identified by the Network-Resource-Id AVP is unknown or is not handled in the 
delegating x-RACF or is not allowed to be delegated to the delegated x-RACF, return a User-Data- Answer 
with the Experimental-Result-Code AVP set to NETWORK_RESOURCE_UNAVAILABLE. 

2) If the network resource identified by the Network-Resource-Id AVP is handled in the delegating x-RACF and 
is allowed to be delegated to the delegated x-RACF, return a User-Data- Answer with the Result-Code AVP set 
to DIAMETER_SUCCESS and populate the Push-Notification-Request as follows: 

a) The Granted-Delegated-Bandwidth-UL shall be present if the uplink bandwidth has been delegated to the 
delegated x-RACF. 

b) The Granted-Delegated-Bandwidth-DL shall be present if the downlink bandwidth has been delegated to 
the delegated x-RACF. 



£75/ 



23 ETSI TS 183 071 V3.1.1 (2010-02) 

5.2.2.6 Event Notification triggered the delegating x-RACF 

If an event for which notification is requested occurs, the delegating x-RACF shall send a CCR message to the 
delegated x-RACF containing: 

• The value of the Specific- Action AVP, indicating the event that occurred. 

• Optionally, the address of the UE that requested the multicast flow and the flow description of the flow. 

• Optionally, the appropriate Abort-Cause AVP value. 

The delegating x-RACF shall send a CCA message to the delegated x-RACF in response to the CCR message. 

5.2.2.7 Event Notification at the delegated x-RACF 

If an event for which notification is requested occurs, the delegated x-RACF shall send an unsolicited RAR message to 
the delegating x-RACF containing: 

• The value of the Specific- Action AVP, indicating the event that occurred. 

• Optionally, the address of the UE that requested the multicast flow and the flow description of the flow. 

• Optionally, the appropriate Abort-Cause AVP value. 

The delegated x-RACF shall send a RAA message to the delegating x-RACF in response to the RAR message. 

6 DIAMETER application for Request IVIodel 

6.1 Use of the Diameter base protocol 

The Rr protocol is based on Diameter (RFC 3588 [8]). 

The Diameter Base Protocol as specified in RFC 3588 [8] used to support information transfer on the Rr interface. 
RFC 3588 [8] shall apply except as modified by the defined Rr application specific procedures, Attribute-Value Pairs 
(AVPs) as well as Experimental-Result-Code AVP and Specific-Action AVP values defined in the present document. 
Unless otherwise specified, the procedures of RFC 3588 [8] (including error handling and unrecognized information 
handling) are unmodified. In addition to the AVPs defined in clause 7.3, the Diameter AVPs from the Diameter base 
application (RFC 3588 [8]) are reused within the Diameter messages sent over the Rr reference point. 

The support of AVPs from the Diameter Network Access Server Application (NASREQ) (RFC 4005 [9]) is not 
required for Diameter implementations that conform to the present document. Accounting functionality (Accounting 
Session State Machine, related command codes and AVPs) is not used in the Rr specification. 

With regard to the Diameter protocol defined over the Rr reference point for request model, the lower-tier x-RACF acts 
as a Diameter server, in the sense that it is the network element that handles authorization requests for a particular 
realm. The top-tier x-RACF acts as the Diameter Client, in the sense that is the network element requesting 
authorization to use bearer path network resources. 

The support of Diameter agents between the lower-tier x-RACF and the top-tier x-RACF, is optional where the Rr is 
intra operator i.e. lower-tier x-RACF and top-tier x-RACF are all in the same domain. 

6.1 .1 Securing Diameter Messages 

For secure transport of Diameter messages, see TS 133 210 [11]. 



6.1 .2 Accounting functionality 



Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used on the 
Rr interface for the Diameter application for the Rr request model. 
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6.1.3 Use of sessions 

The Session-Termination-Request (STR) and Session-Termination-Answer (STA) commands defined in RFC 3588 [8] 
shall be used in order to terminate the sessions. 

6.1 .4 Transport protocol 

Diameter messages over the Rr reference point shall make use of SCTP RFC 4960 [12] and shall utilize the new SCTP 
checksum method specified in RFC 4960 [12]. 

6.1.5 Routing considerations 

Both the Destination-Realm and Destination-Host AVPs shall be present in the request. 

6.1 .6 Advertising Application Support 

The Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) commands are specified in the 
Diameter Base Protocol RFC 3588 [8]. 

The top-tier x-RACF and lower-tier x-RACF shall advertise the support of the Rr specific application for request model 
by including the value 16777278 of the application identifier in the Auth- Application-Id AVP within the 
Vendor-Specific- Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities- 
Exchange- Answer commands. 

The vendor identifier value of ETSI (13019) shall be included in the Vendor-Id AVP of the Capabilities-Exchange- 
Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific- 
Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. 
Additionally, the top-tier x-RACF and the lower-tier x-RACF shall advertise the support of additional Vendor-ID AVPs 
by including the values 10415 (3GPP) in different Supported- Vendor-Id AVP of the CER and CEA commands. 

NOTE: The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer 

commands that is not included in the Vendor-Specific-Application-Id AVPs as described above indicates 
the manufacturer of the Diameter node as per RFC 3588 [8]. 

6.2 Commands 

Existing Diameter command codes from the Diameter base protocol RFC 3588 [8] and RFC 4005 [9] are used at the Rr 
interface. 



6.2.1 AA-Request (AAR) Command 



The AA-Request command (AAR), indicated by the Command-Code field set to 265 and the "R" bit set in the 
Command Flags field, is sent by the top-tier x-RACF to the lower-tier x-RACF for reserve, commit, modify and refresh 
operations. 

Message Format: 

<AA-Request> ::= < Diameter Header: 265, REQ, PXY, 16777278 > 
< Session-Id > 
{ Auth-Application-ID } 
{ Origin-Host } 
{ Origin-Realm } 
{ Destination-Realm } 

Destination-Host ] 

Specific-Action ] 

AF-Charging- Identifier ] 

Media-Component-Description ] 

User-Name ] 
[Logical -Access -Id] 

Globally-Unique-Address ] 

Service-Class ] 

Authorization-Lifetime ] 

Proxy- Info ] 
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* [ Route-Record 

* [ AVP ] 



6.2.2 AA-Answer (AAA) Command 



The AA-Answer command (AAA), indicated by the Command-Code field set to 265 and the "R" bit cleared in the 
Command Flags field, is sent by the lower-tier x-RACF to the top-tier x-RACF in response to the AAR command. 

Message Format: 

<AA-Answer> ::= < Diameter Header: 2S5, PXY, 16777278 > 

< Session-Id > 

{ Auth-Application-ID } 

{ Origin-Host } 

{ Origin-Realm } 

[ Result -Code ] 

[ Experimental-Result ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 

[ Auth-Grace-Period ] 
*[ Session-Bundle-Id ] 

[ Authorization-Lifetime ] 
* [ Failed-AVP ] 
* [ Proxy- Info ] 
* [ AVP ] 

6.2.3 Re-Auth-Request (RAR) Command 

The RAR command, indicated by the Command-Code field set to 258 and the "R" bit set in the Command Flags field, is 
sent by the lower-tier x-RACF to the top-tier x-RACF in order to indicate a specific action. 

The values INDICATION_OF_RELEASE_OF_BEARER, INDICATION_OF_SUBSCRIBER_DETACHMENT, 
INDICATION_OF_RESERVATION_EXPIRATION of the Specific-Action AVP shall not be combined with each 
other in a Re-Auth-Request. 

Message Format: 

<RA-Request> ::= < Diameter Header: 258, REQ, PXY, 16777278 > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

{ Destination-Host } 

{ Auth-Application-Id } 
*{ Specific-Action } 
* [ Flows ] 

[ Abort-Cause ] 
[ Origin-State-Id ] 
* [ Proxy- Info ] 
* [ Route-Record ] 
* [ AVP ] 

6.2.4 Re-Auth-Answer (RAA) Command 

The RAA command, indicated by the Command-Code field set to 258 and the "R" bit cleared in the Command Flags 
field, is sent by the top-tier x-RACF to the lower-tier x-RACF in response to the RAR command. 

Message Format: 

<RA-Answer> ::= < Diameter Header: 258, PXY, 16777278 > 
< Session-Id > 
{ Origin-Host } 
{ Origin-Realm } 
[ Result-Code ] 
[ Experimental-Result ] 

* [ Media-Component-Description ] 
[ Origin-State-Id ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 

* [ Failed-AVP ] 

* [ Proxy- Info ] 
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* [ AVP 



6.2.5 Session-Termination-Request (STR) Command 

The STR command, indicated by the Command-Code field set to 275 and the "R" bit set in the Command Flags field, is 
sent by the top-tier x-RACF to inform the lower-tier x-RACF that an authorized session shall be terminated. 

Message Format: 

<ST-Request> ::= < Diameter Header: 275, REQ, PXY, 16777278 > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

{ Auth-Application-ID } 

{ Termination-Cause } 

[ Destination-Host ] 

* [ Class ] 

[ Origin-State-Id ] 
* [ Proxy- Info ] 
* [ Route-Record ] 

* [ AVP ] 

6.2.6 Session-Termination-Answer (STA) Command 

The STA command, indicated by the Command-Code field set to 275 and the "R" bit cleared in the Command Flags 
field, is sent by the lower-tier x-RACF to the top-tier x-RACF in response to the STR command. 

Message Format: 

<ST-Answer> ::= < Diameter Header: 275, PXY, 16777278 > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

[ Result -Code ] 

[ Experimental-Result ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 
* [ Failed-AVP ] 

[ Origin-State-Id ] 
* [ Redirect-Host ] 

[ Redirect -Host -Usage ] 

[ Redirect-Max-Cache-Time ] 
* [ Proxy- Info ] 

[ AVP ] 

6.2.7 Abort-Session-Request (ASR) Command 

The ASR command, indicated by the Command-Code field set to 274 and the "R" bit set in the Command Flags field, is 
sent by the lower-tier x-RACF to inform the top-tier x-RACF that all resources for the authorized session have become 
unavailable. 

Message Format: 

<AS-Request> ::= < Diameter Header: 274, REQ, PXY, 16777278 > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

{ Destination-Host } 

{ Auth-Application-ID } 

{ Abort-Cause } 
*[ Session-Bundle-Id ] 

[ Origin-State-Id ] 
* [ Proxy- Info ] 
* [ Route-Record ] 

[ AVP ] 
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6.2.8 Abort-Session-Answer (ASA) Command 

The ASA command, indicated by the Command-Code field set to 274 and the "R" bit cleared in the Command Flags 
field, is sent by the top-tier x-RACF to the lower-tier x-RACF in response to the ASR command. 

Message Format: 

<AS-Answer> ::= < Diameter Header: 274, PXY, 16777278 > 

< Session-Id > 

{ Origin-Host } 

{ Origin-Realm } 

[ Result -Code ] 

[ Experimental-Result ] 

[ Origin-State-Id ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 
* [ Failed-AVP ] 
* [ Redirected-Host ] 

[ Redirected-Host-Usage ] 

[ Redirected-Max-Cache-Time ] 
* [ Proxy- Info ] 
* [ AVP ] 

6.3 Experimental-Result-Code AVP values 

6.3.1 Experimental-Result-Code AVP values imported from TS 1 29 209 

This clause lists the specific values of the Experimental-Result-Code AVP imported from TS 129 209 [7] (vendor-id is 
3GPP): 

• INVALID_SERVICE_INFORMATION (5061): 

The service information provided by the top-tier x-RACF is invalid or insufficient for the lower-tier 
x-RACF to perform the requested action. 

• FILTER_RESTRICT10NS (5062): 

The Flow-Description AVP(s) cannot be handled by the lower-tier x-RACF because restrictions defined 
in clause 7.3.7 are not observed. 

6.3.2 Experimental-Result-Code AVP values imported from TS 1 83 026 

This clause lists the specific values of the Experimental-Result-Code AVP imported from TS 183 026 [10] (vendor-id is 
ESTI): 

• INSUFFICIENT_RESOURCES (4041): 

The lower-tier x-RACF indicates insufficient resources to perform the requested action. 

• MODIFlCAT10N_FAlLURE (5041): 

The lower-tier x-RACF or BGF indicates that the resources reservation could not be modified. This is a 
permanent failure. 

• C0MM1T_FAILURE (4043): 

The lower-tier x-RACF indicates that the resources reservation could not be committed. 

• REFRESH_FA1LURE (4044): 

The lower-tier x-RACF indicates that the lifetime of a reservation could not be extended. 

• QOS_PROFILE_FAILURE (4045): 

The lower- tier x-RACF indicates that the request did not match the QoS profile. 
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ACCESS_PROFILE_FAILURE (4046): 

The lower-tier x-RACF indicates that the request did not match any access profile. 
PRIORITY_NOT_GRANTED (4047): 

The lower-tier x-RACF indicates that the priority level of the request is not accepted. 



6.4 Use of namespaces 



This clause contains the namespaces that have either been created in the present document for the Rr request model, or 
the values assigned to existing namespaces managed by lANA. 

6.4.1 AVP codes 

The present document does not define any new AVPs for the Diameter application for the Rr request model. 

6.4.2 Experimental-Result-Code AVP values 

The present document does not define any new Experimental-Result-Code AVP values for the Diameter application for 
the Rr request model. 

6.4.3 Command Code values 

The present document does not assign command code values but uses existing command codes for the Diameter 
application for the Rr request model. 

6.4.4 Application-ID value 

The present document uses value 16777278, allocated by lANA, as application identifier for the Diameter application 
for the Rr request model. 

6.5 AVPs 

This clause summarizes the AVPs used in the present document for the Diameter application for the Rr request model, 
beyond those defined in the Diameter Base Protocol. 

The present document does not define any new AVPs for the Diameter application for the Rr request model. 
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Table 6.1 describes the Diameter AVPs imported from 129 209 [7]. The Vendor-Id header for these AVPs shall be set 
to 3GPP (10415). 

Table 6.1 : Diameter AVPs imported from TS 129 209 [7] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May 
encrypt 


Abort-Cause 


500 


6.5.1 


Enumerated 


M,V 


P 






Y 


AF-Application-ldentifier 


504 


6.5.2 


OctetString 


M,V 


P 






Y 


AF-Charging-ldentifier 


505 


6.5.3 


OctetString 


M,V 


P 






Y 


Flow-Description 


507 


6.5.4 


IPFilterRule 


M,V 


P 






Y 


Flow-Number 


509 


6.5.5 


Unsigned32 


M,V 


P 






Y 


Flows 


510 


6.5.6 


Grouped 


M,V 


P 






Y 


Flow-Status 


511 


6.5.7 


Enumerated 


M,V 


P 






Y 


Flow-Usage 


512 


6.5.8 


Enumerated 


M,V 


P 






Y 


Specific-Action 


513 


6.5.9 


Enumerated 


M,V 


P 






Y 


IVIax-Requested-Bandwidth-DL 


515 


6.5.10 


Unsigned32 


M,V 


P 






Y 


Max-Requested-Bandwidth-UL 


516 


6.5.11 


Unsigned32 


M,V 


P 






Y 


Media-Component-Description 


517 


6.5.12 


Grouped 


M,V 


P 






Y 


Media-Component-Number 


518 


6.5.13 


Unsigned32 


M,V 


P 






Y 


Media-Sub-Component AVP 


519 


6.5.14 


Grouped 


M,V 


P 






Y 


Media-Type 


520 


6.5.15 


Enumerated 


M,V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [8]. 

NOTE 2: The value types are defined in RFC 3588 [8]. 



Table 6.2 describes the Diameter AVPs imported from TS 183 017 [5]. The Vendor-Id header for these AVPs shall be 
set to ETSI (13019). 

Table 6.2: Diameter AVPs imported from TS 183 017 [5] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May 
encrypt 


Reservation-Class 


456 


6.5.16 


Unsigned32 


M,V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 

bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For further 
details, see RFC 3588 [8]. 

NOTE 2: The value types are defined in RFC 3588 [8]. 



Table 6.3 describes the Diameter AVPs imported from ES 283 034 [4]. The Vendor-Id header for these AVPs shall be 
set to ETSI (13019). 

Table 6.3: Diameter AVPs imported from [4] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May 
encrypt 


Globally-Unique-Address 


300 


6.5.17 


Grouped 


M, V 


P 






Y 


Address-Realm 


301 


6.5.18 


OctetString 


M, V 


P 






Y 


Logical-Access-Id 


302 


6.5.19 


OctetString 


M,V 


P 






Y 


Transport-Class 


311 


6.5.20 


Unsigned32 


M,V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [8]. 

NOTE 2: The value types are defined in RFC 3588 [8]. 
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Table 6.4 describes the Diameter AVPs imported from TS 183 026 [10]. The Vendor-Id header for these AVPs shall be 

set to ETSI (13019). 

Table 6.4: Diameter AVPs imported from TS 183 026 [10] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May 
encrypt 


Session-Bundle-ld 


400 


6.5.21 


Unsigned32 


M,V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [8]. 

NOTE 2: The value types are defined in RFC 3588 [8]. 



6.5.1 Abort-Cause AVP 

The Abort-Cause AVP (AVP code 500) is of type Enumerated, and it determines the cause of an ASR. The following 
values defined in 129 209 [7] are used: 

• BEARER_RELEASED (0): 

This value is used when the bearer has been deactivated as a result from normal signalling handling. For 
xDSL, the bearer may refer to an ATM VC. 

• INSUFFICIENT_SERVER_RESOURCES (1): 

This value is used to indicate that the lower-tier x-RACF is overloaded and needs to abort the session. 

• INSUFFICIENT_BEARER_RESOURCES (2): 

This value is used when the bearer has been deactivated due to insufficient bearer resources at a transport 
gateway (e.g. RCEF policies being removed on an xDSL line). 

6.5.2 AF-Application-ldentifier AVP 

The AF- Application-Identifier AVP (AVP code 504) is of type OctetString, and contains information that identifies the 
RACS client requesting the resources (e.g. name of an ASP or group of ASPs). 

6.5.3 AF-Charging-ldentifier AVP 

The AF-Charging-Identifier AVP (AVP code 505) is of type OctetString, contains the AF Charging Identifier that is 
sent by the AF. This information may be used for charging correlation between AF and RACS functional entities. 



6.5.4 Flow-Description AVP 



• The Flow-Description AVP (AVP code 507) is of type IPFilterRule, and defines a packet filter for an IP flow 
with the following information: Direction (in or out). 

• Source and destination IP address (possibly masked). 

• Protocol. 

• Source and destination port (list or ranges). 

The IPFilterRule type shall be used with the following restrictions: 

• Only the Action "permit" shall be used. 

• No "options" shall be used. 

• The invert modifier " !" for addresses shall not be used. 
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The keyword "assigned" shall not be used. 



If any of these restrictions is not observed by the top-tier x-RACF, the lower-tier x-RACF shall send an error response 
to the top-tier x-RACF containing the Experimental-Result-Code AVP with value FILTER_RESTRICTIONS. 

The Flow description AVP shall be used to describe a single IP flow. 

The direction "in" refers to IP flows from the subscriber into the access network ("uplink"), and the direction "out" 
refers to IP flows from the access network to the subscriber ("downlink"). 

6.5.5 Flow-Number AVP 

The Flow-Number AVP (AVP code 509) is of type Unsigned32, and it contains the ordinal number of the IP flow(s), 
assigned according to the rules in annex C of TS 129 207 [13]. 

6.5.6 Flows AVP 

The Flows AVP (AVP code 510) is of type Grouped, and it indicates IP flows via their flow identifiers. If no 
Flow-Number AVP(s) are supplied, the Flows AVP refers to all Flows matching the media component number. 

AVP Format: 

Flows: := < AVP Header: x > 

{ Media-Component-Number} 
* [ Flow-Number] 

6.5.7 Flow-Status AVP 

The Flow-Status AVP (AVP code 5 11) is of type Enumerated, and describes whether the IP flow(s) are enabled or 
disabled. The Flow-Status AVP may be present in the Media-Description-Component AVP and/or in the 
Media-Sub-Component AVP. The following values are defined: 

• ENABLED-UPLINK (0): 

This value shall be used to commit the corresponding resource reservation in the uplink direction. 

• ENABLED-DOWNLINK (1): 

This value shall be used to commit the corresponding resource reservation in the downlink direction. 

• ENABLED (2): 

This value shall be used to commit a resource reservation in both directions. 

• DISABLED (3): 

This value shall be used to indicate that the corresponding resource reservation is reserved only and not 
(yet) committed. 

• REMOVED (4): 

This value shall be used to release all resources associated with the corresponding resource reservation. 



6.5.8 Flow-Usage AVP 



The Flow-Usage AVP (AVP code 5 12) is of type Enumerated, and it provides information about the usage of IP Flows. 
The following values are defined: 

• NOJNFORMATION (0): 

This value is used to indicate that no information about the usage of the IP flow is being provided. 
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• RTCP (1): 

This value is used to indicate that an IP flow is used to transport RTCP. 

• NO_INFORMATION is the default value. 

6.5.9 Specific-Action AVP 

The Specific- Action AVP (AVP code 513) is of type Enumerated. Within an initial AA-Request the top-tier x-RACF 
may use the Specific-Action AVP to request from the lower-tier x-RACF notification of specific actions. If the 
Specific-Action AVP is omitted within the initial AA-Request, no notification of any of the events defined below is 
requested. 

The following event from TS 129 209 [7] is supported: 

• INDICATION_OF_RELEASE_OF_BEARER (4): 

Within an AAR, this value shall be used when the lower-tier x-RACF reports to the top-tier x-RACF the 
release of a bearer (e.g. RCEF policies being removed on an xDSL line). In the AAR, this value indicates 
that the top-tier x-RACF requests the lower-tier x-RACF to provide a notification at the removal of a 
bearer. 

The following events from TS 183 026 [10] are supported: 

• INDICATION_OF_SUBSCRIBER_DETACHMENT (6): 

Within an AAR, this value shall be used when the lower-tier x-RACF reports to the top-tier x-RACF that 
a subscriber has been detached. In the AAR, this value indicates that the top-tier x-RACF requests the 
lower-tier x-RACF to provide a notification at the detachment of a subscriber. 

• INDICATION_OF_RESERVATION_EXPIRATION (7): 

Within an AAR, this value shall be used when the lower-tier x-RACF reports to the top-tier x-RACF that 
a reservation is about to expire. In the AAR, this value indicates that the top-tier x-RACF requests the 
lower-tier x-RACF to provide a notification when a reservation expires. 

Other events but the above-listed ones defined by TS 129 209 [7] are not relevant at the Rr interface and are not 
supported. If specified by the top-tier x-RACF, these values are ignored by the lower-tier x-RACF. 

6.5.1 Max-Requested-Bandwidtin-DL AVP 

The Max-Requested-Bandwidth-DL AVP (AVP code 515) is type Unsigned32, and it indicates the maximum requested 
bandwidth in bits per second for a downlink IP flow. The bandwidth includes the bandwidth of the IP payload, 
including the overhead coming from the IP header. 

6.5.1 1 Max-Requested-Bandwidtin-UL AVP 

The Max -Bandwidth-UL AVP (AVP code 516) is of type Unsigned32, and it indicates the maximum requested 
bandwidth in bits per second for an uplink IP flow. The bandwidth includes the bandwidth of the IP payload, including 
the overhead coming from the IP header. 

6.5.12 Media-Component-Description AVP 

The Media-Component-Description AVP (AVP code 517) is of type Grouped, and it contains service information for a 
single media component within a session. It may be based on the SDI exchanged between the AF and the AF client in 
the UE. The information shall be used by the lower-tier x-RACF to determine the QoS requirements. 

Within one Diameter message, a single IP flow shall not be described by more than one Media-Component-Description 
AVP. 

The Media-Component-Description AVP may contain the Flow-Status AVP, which indicates the particular reservation 
operation to be performed on the media, as described in clauses 5.1 and 5.2. 
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Bandwidth information provided within the Media-Component-Description AVP applies to all those IP flows within the 
media component, for which no corresponding information is being provided within Media-Sub-Component AVP(s). 

If a Media-Component-Description AVP is not supplied, or if optional AVP(s) within a Media-Component-Description 
AVP are omitted, but corresponding information has been provided in previous Diameter messages, the previous 
information for the corresponding IP flow(s) remains valid. 

AVP format: 

Media-Component-Description ::= < AVP Header: 517> 

{ Media-Component-Number } ; Ordinal number of the media comp. 
Media-Sub-Component ] ; Set of flows for one flow identifier 
AF-Application-Identif ier ] 
Media-Type ] 

Max-Requested-Bandwidth-UL ] 
Max-Requested-Bandwidth-DL ] 
Flow-Status ] 
RS-Bandwidth ] 
RR-Bandwidth ] 
Reservation-Class ] 
Transport-Class ] 



6.5.1 3 Media-Component-Number AVP 

The Media-Component-Number AVP (AVP code 518) is of type Unsigned32, and it contains the ordinal number of the 
media component, assigned according to the rules in annex C of TS 129 207 [13]. 

6.5.14 Media-Sub-Component AVP 

The Media-Sub-Component AVP (AVP code 519) is of type Grouped, and it contains the requested QoS and filters for 
the set of IP flows identified by their common Flow-Identifier. The Flow-Identifier is defined in TS 129 207 [13]. 

The Media-Sub-Component AVP may contain the Flow-Status AVP, which indicates the particular reservation 
operation to be performed on the flow, as described in clauses 5.1 and 5.2. 

Possible Bandwidth information provided within the Media-Sub-Component AVP takes precedence over information 
within the encapsulating Media Component Description AVP. If a Media-Sub-Component AVP is not supplied, or if 
optional AVP(s) within a Media-Sub-Component AVP are omitted, but corresponding information has been provided in 
previous Diameter messages, the previous information for the corresponding IP flow(s) remains valid, unless new 
information is provided within the encapsulating Media-Component-Description AVP. If Flow-Description AVP(s) are 
supplied, they replace all previous Flow-Description AVP(s), even if a new Flow-Description AVP has the opposite 
direction as the previous Flow-Description AVP. 

AVP Format: 

Media-Sub-Component ::= < AVP Header: 519 > 

{ Flow-Number } ; Ordinal number of the IP flow 
[ Flow-Status ] 
0*2 [ Flow-Description ] ; UL and/or DL 
[ Flow-Usage ] 

[ Max-Requested-Bandwidth-UL ] 
[ Max-Requested-Bandwidth-DL ] 

6.5.15 Media-Type AVP 

The Media-Type AVP (AVP code 520) is of type Enumerated, and it determines the media type of a session 
component. The following values are defined: 

• AUDIO (0). 

• VIDEO (1). 

• DATA (2). 

• APPLICATION (3). 
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• CONTROL (4). 

• TEXT (5). 

• MESSAGE (6). 

• OTHER (OxFFFFFFFF). 

6.5.16 Reservation-Class AVP 

The Reservation-Class AVP (AVP code 456) is of type Unsigned32, and it contains an integer used as an index pointing 
to the traffic characteristics of the flow (e.g. burstiness and packet size). 

6.5.17 Globally-Unique-Address AVP 

The Globally-Unique-Address AVP (AVP code 300) is of type Grouped. 
AVP Format: 

Globally-Unique-Address ::= < AVP Header: 300 13019 > 

[Framed- IP-Address] 
[Framed- IPv6 -Prefix] 
[Address -Realm] 

6.5.18 Address-Realm AVP 

The Address-Realm AVP (AVP code 301) is of type OctetString. 

6.5.19 Logical-Access-ID AVP 

The Logical-Access-ID AVP (AVP code 302 13019) is of type OctetString. It is defined in ES 283 034 [4]. 

6.5.20 Session-Bundle-ld AVP 

The Session-Bundle-Id (AVP code 400) is of type Unsigned32. It may be specified by the lower-tier x-RACF in the 
AA- Answer, when the initial reservation is granted, in order to identify the group of sessions to which the session of the 
AA- Answer belongs. The value of the Session-Bundle-Id AVP is meaningful for the lower-tier x-RACF only. It may be 
included by the lower-tier x-RACF in subsequent Abort-Session-Request (ASR) messages sent to the top-tier x-RACF. 

6.5.21 Transport-Class AVP 

The Transport-Class AVP (AVP code 311) is of type Unsigned32, and it contains an integer used as an index pointing 
to a class of transport services to be applied (e.g. forwarding behaviour). 

7 DIAMETER application for Delegated Model 

With the clarifications listed in the following clauses the Diameter base protocol defined by RFC 3588 [8] shall apply. 

7.1 Use of the Diameter base protocol 
7.1 .1 Securing Diameter messages 

For secure transport of Diameter messages, IPSec may be used. Guidelines on the use of SCTP with IPSec can be found 
in RFC 3554 [14]. 
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7.1.2 Accounting functionality 



Accounting functionality (accounting session state machine, related command codes and AVPs) is not used for the 
delegated model of the Rr interface. 

7.1.3 Use of sessions 

Diameter sessions are implicitly terminated. An implicitly terminated session is one for which the server does not 
maintain state information. The client does not need to send any re-authorization or session termination requests to the 
server. 

The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of 
implicitly terminated sessions. 

The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value 
NO_STATE_MAINTAINED (1), as described in RFC 3588 [8]. As a consequence, the server does not maintain any 
state information about this session and the client does not need to send any session termination request. Neither the 
Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 



7.1 .4 Transport protocol 



Diameter messages over the delegated model of the Rr interface shall make use of SCTP RFC 4960 [12] and shall 
utilize the new SCTP checksum method specified in RFC 4960 [12]. 

7.1.5 Routing considerations 

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. 

Requests initiated by the delegating x-RACF towards the RACS shall include both Destination-Host and 
Destination-Realm AVPs. The delegating x-RACF obtains the Destination-Host AVP to use in requests towards a 
delegated x-RACF, from configuration data and/or the NASS User profile. Consequently, the Destination-Host AVP is 
declared as mandatory in the ABNF for all requests initiated by the delegating x-RACF. 

Requests initiated by the delegated x-RACF towards the delegating x-RACF shall include both Destination-Host and 
Destination-Realm AVPs. The delegated x-RACF obtains the Destination-Host AVP to use in requests towards a 
delegating x-RACF, from the Origin-Host and Origin-Realm AVPs received in previous commands from the delegating 
x-RACF. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by 
the delegated x-RACF. 

Destination-Realm AVP is declared as mandatory in the ABNF for all requests. 



7.1 .6 Advertising application support 



The delegating x-RACF and the delegated x-RACF shall advertise support of the Rr specific application for delegated 
model by including the value 16777279 of the application identifier in the Auth- Application-Id AVP within the 
Vendor-Specific- Application-Id grouped AVP of the Capabilities-Exchange-Request and 
Capabilities-Exchange-Answer commands. 

The vendor identifier value of ETSI (13019) shall be included in the Supported- Vendor-Id AVP of the 
Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the 
Vendor-Specific- Application-Id grouped AVP of the Capabilities-Exchange-Request and 

Capabilities-Exchange-Answer commands. Additionally, support of 3GPP AVPs shall be advertised by adding the 
vendor identifier value of 3GPP (10415) to the Supported- Vendor-Id AVP of the Capabilities-Exchange-Request and 
Capabilities-Exchange-Answer commands. 

NOTE: The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange- Answer 

commands that is not included in the Vendor-Specific-Application-Id AVPs as described above indicates 
the manufacturer of the Diameter node as per RFC 3588 [8]. 
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7.2 



Commands 



The Rr interface for Rr delegated model re-uses and modifies commands defined in TS 129 329 [15], RFC 3588 [8] or 
RFC 4006 [6] as follows. 

Table 7.1 : Command-code values 



Command-Name 


Abbreviation 


Code 


Defined In 


User-Data-Request 


UDR 


306 


TS 129 329 [15] 


User-Data-Answer 


UDA 


306 


TS 129 329 [15] 


Push-Notification-Request 


PNR 


309 


TS 129 329 [15] 


Push-Notification-Answer 


PNA 


309 


TS 129 329 [15] 


Re-Auth-Request 


RAR 


258 


RFC 3588 [8] 


Re-Auth-Answer 


RAA 


258 


RFC 3588 [8] 


CC-Request 


CCR 


272 


RFC 4006 [6] 


CC-Answer 


CCA 


272 


RFC 4006 [6] 



AVPs defined in TS 129 329 [15], RFC 3588 [8] or RFC 4006 [6] and not used in the Rr interface for Rr delegated 
model are not shown in the below clauses. If received, these AVPs shall be ignored by the delegating x-RACF and the 
delegated x-RACF. 

New AVPs are represented in bold. 



7.2.1 User-Data-Request command 

The User-Data-Request (UDR) command, indicated by the Command-Code field set to 306 and the "R" bit set in the 
Command Flags field, is sent by a delegated x-RACF to a delegating x-RACF to request an operation on delegation. 



Message Format: 



< User-Data -Request > 



< Diameter Header: 306, REQ, PXY, 16777279> 

< Session-Id > 

{ Vendor-Specif ic-Application-Id } 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[ Destination-Host ] 

{ Destination-Realm } 

[Network-Resource- Id] 

[Preferred- Delegated- Bandwidth-UL] 

[Preferred- Delegated- Bandwidth- DL] 

[Required- Delegated- Bandwidth-UL] 

[Required- Delegated- Bandwidth- DL] 

[Reservation-priority] 

* [ AVP ] 

* [ Proxy- Info ] 

* [ Route-Record ] 



7.2.2 User-Data-Answer command 



The User-Data-Answer (UDA) command, indicated by the Command-Code field set to 306 and the "R" bit cleared in 
the Command Flags field, is sent by a delegating x-RACF in response to the User-Data-Request command. 



Message Format: 



< User-Data-Answer > 



< Diameter Header: 306, PXY, 16777279> 

< Session-Id > 

{ Vendor-Specif ic-Application-Id } 

[ Result-Code ] 

[ Experimental-Result ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[Granted- Delegated- Bandwidth-UL] 

[Granted- Delegated- Bandwidth- DL] 

[Total -Bandwidth-UL] 

[Total -Bandwidth-DL] 
* [ AVP ] 
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[ Failed-AVP ] 
[ Proxy- Info ] 
[ Route-Record 



7.2.3 Push-Notification-Request command 



The Push-Notification-Request (PNR) command, indicated by the Command-Code field set to 309 and the "R" bit set in 
the Command Flags field, is sent by a delegating x-RACF to a delegated x-RACF to request an operation on delegation. 



Message Format: 

< Push-Notification-Request > 



Diameter Header: 309, REQ, PXY, 16777279> 

Session-Id > 

Vendor-Specif ic-Application-Id } 

Auth-Session-State } 

Origin-Host } 

Origin-Realm } 

Destination-Host } 

Destination-Realm } 
[Network-Resource- Id] 
[Granted- Delegated- Bandwidth-UL] 
[Granted- Delegated- Bandwidth- DL] 
[Preferred- Delegated- Bandwidth-UL] 
[Preferred- Delegated- Bandwidth- DL] 
[Required- Delegated- Bandwidth-UL] 
[Required- Delegated- Bandwidth-DL] 
[Reservation-priority] 
[Total -Bandwidth-UL] 
[Total -Bandwidth-DL] 
*[ Authorization-Package-Id ] 
* [ AVP ] 
* [ Proxy- Info ] 
* [ Route-Record ] 



7.2.4 Pusin-Notification-Answer command 

The Push-Notifications-Answer (PNA) command, indicated by the Command-Code field set to 309 and the "R" bit 
cleared in the Command Flags field, is sent by a delegated x-RACF in response to the Push-Notification-Request 
command. 



Message Format: 



< Push-Notification-Answer > 



< Diameter Header: 309, PXY, 16777279> 

< Session-Id > 

{ Vendor-Specif ic-Application-Id } 

[ Result-Code ] 

[ Experimental-Result ] 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 

[Granted- Delegated- Bandwidth-UL] 

[Granted- Delegated- Bandwidth-DL] 

[Total -Bandwidth-UL] 

[Total -Bandwidth-DL] 
* [ AVP ] 
* [ Failed-AVP ] 
* [ Proxy- Info ] 
* [ Route-Record ] 
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7.2.5 Re-Auth-Request (RAR) Command 



The RAR command, indicated by the Command-Code field set to 258 and the "R" bit set in the Command Flags field, is 
sent by the delegated x-RACF to the delegating x-RACF in order to indicate a specific action. 

The values INDICATION_OF_RELEASE_OF_BEARER, INDICATION_OF_SUBSCRIBER_DETACHMENT and 
INDICATION_OF_RESERVATION_EXPIRATION of the Specific-Action AVP shall not be combined with each 
other in a Re-Auth-Request. 



Message Format: 



<RA-Request> 



25£ 



Diameter Header 
Session-Id > 
Auth-Session-State } 
Origin-Host } 
Origin-Realm } 
Destination-Host } 
Destination-Realm } 
Auth-Application-Id } 
*{ Specific-Action } 

* [ Flow-Description ] 

[ Globally-Unique-Address ] 

[ Logical-Access-Id ] 

[ Abort-Cause ] 

[ Origin-State-Id ] 
* [ Proxy- Info ] 
* [ Route-Record ] 

* [ AVP ] 



REQ, PXY, 16777279> 



7.2.6 Re-Auth-Answer (RAA) command 

The RAA command, indicated by the Command-Code field set to 258 and the "R" bit cleared in the Command Flags 
field, is sent by the delegating x-RACF to the delegated x-RACF in response to the RAR command. 



Message Format: 



<RA-Answer> 



< Diameter Header: 258, 

< Session-Id > 

{ Auth-Session-State } 

{ Origin-Host } 

{ Origin-Realm } 
[ Result-Code ] 
[ Experimental-Result ] 
[ Origin-State-Id ] 
[ Error-Message ] 
[ Error-Reporting-Host 

* [ Failed-AVP ] 

* [ Proxy- Info ] 

* [ AVP ] 



PXY, 16777279> 



7.2.7 CC-Request (CCR) command 



The CCR command, indicated by the Command-Code field set to 272 and the "R" bit set in the Command Flags field, is 
sent by the delegating x-RACF to the delegated x-RACF in order to report the occurrence of particular event. 



Message Format: 



<CC-Request> ::= 



Diameter Header: 272, REQ, PXY, 1S777279> 

Session-Id > 

Auth-Session-State } 

Origin-Host } 

Origin-Realm } 

Destination-Realm } 

Destination-Host } 

Auth-Application-Id } 
*{ Specific-Action } 
* [ Flow-Description ] 
[ Globally-Unique-Address ] 
[ Logical-Access-Id ] 
[ Abort-Cause ] 
[ Origin-State-Id ] 
* [ Proxy- Info ] 
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* [ Route-Record 
* [ AVP ] 



7.2.8 CC-Answer (CCA) Command 



The Credit-Control- Answer message (CCA) is indicated by the command-code field being set to 272 and the "R" bit 
being cleared in the Command Flags field. It is sent by the delegated x-RACF to the delegating x-RACF in answer to 
the CCR. 

Message Format: 

<CC-Answer> ::= < Diameter Header: 272, PXY, 16777279> 
< Session-Id > 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
{ Auth-Application-Id } 

[ Result-Code ] 

[ Experimental-Result ] 

[ Origin-State-Id ] 

[ Error-Message ] 

[ Error-Reporting-Host ] 
* [ Failed-AVP ] 
* [ Proxy- Info ] 
* [ AVP ] 

7.3 Experimental-Result-Code AVP values 

7.3.1 Experimental-Result-Code AVP values imported from ES 283 034 

The present document reuses existing Experimental-Result-Code AVP values defined in ES 283 034 [4] as follows: 

• DIAMETER_SYSTEM_UNAVAILABLE (4001): 

This error is returned when a request could not be satisfied at the time that it was received due to a 
temporary internal failure or congestion. When this result code is used, the ETSI Vendor ID shall be 
included in the Vendor-Id AVP of the Experimental-Result AVP. 

7.3.2 Experimental-Result-Code AVP values defined in the present 
document 

This clause defines the specific values of the Experimental-Result-Code AVP (vendor-id is ETSI) for the Diameter 
application for the Rr delegated model: 

• NETWORK_RESOURCE_UNAVAILABLE (4061): 

The delegating or delegated x-RACF indicates the network resource identified by the Network-Resource- 
Id AVP is unknown or is not handled in the current entity or is not allowed to be delegated between the 
delegating x-RACF and the delegated x-RACF. 

• NETWORK_RESOURCE_INSUFFICIENT (4062): 

The delegating or delegated x-RACF indicates there is insufficient network resource to perform the 
requested action. 



7.4 Use of namespaces 



This clause contains the namespaces that have either been created in the present document for the Rr delegated model, 
or the values assigned to existing namespaces managed by lANA. 
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7.4.1 AVP codes 

The present document assigns the AVP values in the 650 to 699 range from the AVP Code namespace managed by 
ETSI for the Diameter application for the Rr delegated model. See clause 7.5 for the assigned values. 

7.4.2 Experimental-Result-Code AVP values 

The present document assigns the Experimental-Result-Code AVP values from the AVP Code namespace managed by 
ETSI for the Diameter application for the Rr delegated model. See clause 7.3 for the assigned values. 

7.4.3 Command Code values 

The present document does not assign command code values but uses existing command codes for the Diameter 
application for the Rr delegated model. 

7.4.4 Application-ID value 

The present document uses value 16777279, allocated by lANA, as application identifier for the Diameter application 
for the Rr delegated model. 



7.5 



AVPs 



This clause summarizes the AVPs used in the present document for the Diameter application for the Rr delegated 
model, beyond those defined in the Diameter Base Protocol. 

Table 7.2 describes the Diameter AVPs defined in the present document, their AVP Code values, types, possible flag 
values and whether the AVP may be encrypted. The vendor-Id header of all AVPs defined in the present document shall 
be set to ETSI (13019). 

Table 7.2: Diameter AVPs defined in the present document 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Sliould 
not 


Must 
not 


May 
encrypt 


Network-Resource-Id 


650 


7.5.1 


OctetString 


M,V 


P 






Y 


Preferred-Delegated- 
Bandwidth-UL 


651 


7.5.2 


Unsigned32 


M,V 


P 






Y 


Preferred-Delegated- 
Bandwidth-DL 


652 


7.5.3 


Unsigned32 


M,V 


P 






Y 


Required-Delegated- 
Bandwidth-UL 


653 


7.5.4 


Unsigned32 


M,V 


P 






Y 


Required-Delegated- 
Bandwidth-DL 


654 


7.5.5 


Unsigned32 


M,V 


P 






Y 


Granted-Delegated- 
Bandwidth-UL 


655 


7.5.6 


Unsigned32 


M,V 


P 






Y 


Granted-Delegated- 
Bandwidth-DL 


656 


7.5.7 


Unsigned32 


M,V 


P 






Y 


Total-Bandwidth-UL 


657 


7.5.8 


Unsigned32 


M,V 


P 






Y 


Total-Bandwidth-DL 


658 


7.5.9 


Unsigned32 


M,V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [8]. 

NOTE 2: The value types are defined in RFC 3588 [8]. 



Table 7.3 describes the Diameter AVPs imported from TS 183 017 [5]. The Vendor-Id header of these AVPs shall be 
set to ETSI (13019). 
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Table 7.3: Diameter AVPs imported from TS 183 017 [5] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May 
encrypt 


Reservation-Priority 


458 


7.5.10 


Enumerated 


V 






M 


Y 


Authorization-Pacl<age-ld 


461 


7.5.11 


UTFSString 


V 






M 


Y 


NOTE 1 : The AVP header bit denoted as "IVI", indicates whether support of the AVP is required. The AVP header 

bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For further 
details, see RFC 3588 [8]. 

NOTE 2: The value types are defined in RFC 3588 [8]. 



Table 7.4 describes the Diameter AVPs imported from TS 129 209 [7]. The Vendor-Id header for these AVPs shall be 
set to 3GPP (10415). 

Table 7.4: Diameter AVPs imported from TS 129 209 [7] 











AVP Flag rules (see note 1) 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 
(see note 2) 


Must 


May 


Should 
not 


Must 
not 


May 
encrypt 


Abort-Cause 


500 


7.5.12 


Enumerated 


M,V 


P 






Y 


Flow-Description 


507 


7.5.13 


IPFIIterRule 


M,V 


P 






Y 


Specific-Action 


513 


7.5.14 


Enumerated 


M,V 


P 






Y 


NOTE 1 : The AVP header bit denoted as "IVI", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see RFC 3588 [8]. 

NOTE 2: The value types are defined in RFC 3588 [8]. 



Table 7.5 describes the Diameter AVPs imported from ES 283 034 [4]. The Vendor-Id header of these AVPs shall be 
set to ETSI (13019). 

Table 7.5: Diameter AVPs imported from e4 interface ES 283 034 [4] 











AVP Flag rules 




Attribute Name 


AVP 
Code 


Clause 
defined 


Value Type 


Must 


May 


Should 
not 


Must 
not 


May 
Encrypt 


Globally-Unique-Address 


300 


7.5.15 


Grouped 


V 






M 


Y 


Address-Realm 


301 


7.5.16 


OctetString 


V 






M 


Y 


Logical-Access-Id 


302 


7.5.17 


OctetString 


V 


M 






Yes 


NOTE: The AVP header bit denoted as "IVI", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For 
further details, see TS 1 33 21 [1 1 ]. 



Table 7.6 describes the Diameter AVPs imported from RFC 4005 [9]. No Vendor-Id header shall be included in these 
AVPs. 

Table 7.6: Diameter AVPs imported from RFC 4005 [9] 











AVP Flag rules 




Attribute Name 


AVP 
Code 


Section 
defined 


Value Type 


Must 


May 


Should 
not 


Must 
not 


May 
Encrypt 


Framed-! P-Address 


8 


7.5.18 


OctetString 








V,M 


Y 


Framed-IPv6-Prefix 


97 


7.5.19 


OctetString 








V,M 


Y 



7.5.1 



Network-Resource-l(d AVP 



The Network-Resource-Id AVP (AVP code 650) is of type OctetString, it contains the identifier of the network 
resource. 
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7.5.2 Preferred-Delegated-Bandwidth-UL AVP 

The Preferred-Delegated-Bandwidth-UL AVP (AVP code 651) is type Unsigned32, and it indicates the preferred 
delegated bandwidth requested in kbits per second in the uplink direction. 

7.5.3 Preferred-Delegated-Bandwidth-DL AVP 

The Preferred-Delegated-Bandwidth-DL AVP (AVP code 652) is type Unsigned32, and it indicates the preferred 
delegated bandwidth requested in kbits per second in the downlink direction. 

7.5.4 Required-Delegated-Bandwidth-UL AVP 

The Required-Delegated-Bandwidth-UL AVP (AVP code 653) is type Unsigned32, and it indicates the required 
delegated bandwidth requested in kbits per second in the uplink direction. 

7.5.5 Required-Delegated-Bandwidth-DL AVP 

The Required-Delegated-Bandwidth-DL AVP (AVP code 654) is type Unsigned32, and it indicates the required 
delegated bandwidth requested in kbits per second in the downlink direction. 

7.5.6 Granted-Delegated-Bandwidth-UL AVP 

The Granted-Delegated-Bandwidth-UL AVP (AVP code 655) is type Unsigned32, and it indicates the granted delegated 
bandwidth in kbits per second in the uplink direction. 

7.5.7 Granted-Delegated-Bandwidth-DL AVP 

The Granted-Delegated-Bandwidth-DL AVP (AVP code 656) is type Unsigned32, and it indicates the granted delegated 
bandwidth in kbits per second in the downlink direction. 

7.5.8 Total-Bandwidth-UL AVP 

The Total-Bandwidth-UL AVP (AVP code 657) is type Unsigned32, and it indicates the total bandwidth in kbits per 
second in the uplink direction. 

7.5.9 Total-Bandwidth-DL AVP 

The Total-Bandwidth-DL AVP (AVP code 658) is type Unsigned32, and it indicates the total bandwidth in kbits per 
second in the downhnk direction. 

7.5.10 Reservation-priority AVP 

The Reservation-Priority AVP (AVP code 458) is of type Enumerated. The following values are specified. 

DEFAULT (0): This is the lowest level of priority. If no Reservation-Priority AVP is specified in the AA-Request, this 
is the priority associated with the reservation. 

PRIORITY-ONE (1). 

PRIORITY-TWO (2). 

PRIORITY-THREE (3). 

PRIORITY-FOUR (4). 

PRIORITY-FIVE (5). 

PRIORITY-SIX (6). 
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PRIORITY-SEVEN (7). 
PRIORITY-EIGHT (8). 
PRIORITY-NINE (9). 
PRIORITY-TEN (10). 
PRIORITY-ELEVEN (11). 
PRIORITY-TWELVE (12). 
PRIORITY-THIRTEEN (13). 
PRIORITY-FOURTEEN (14). 
PRIORITY-FIFTEEN (15). 

7.5.1 1 Authorization-Package-Id AVP 

The Authorization-Package-Id AVP (AVP code 461) is of type UTFSString, and it identifies an authorization context 
requested by the AF for the session and passed transparently through Rq. This information is used by the delegated 
x-RACF to derive the policy to be passed to an RCEF through the Re reference point for the session. 

7.5.12 Abort-Cause AVP 

The Abort-Cause AVP (AVP code 500) is of type Enumerated, and it determines the cause of an ASR. The following 
values defined in TS 129 209 [7] are used: 

• INSUFFICIENT_SERVER_RESOURCES (1): 

This value is used to indicate that the x-RACF is overloaded. 

• INSUFFICIENT_BEARER_RESOURCES (2): 

This value is used when the bearer has been deactivated due to insufficient bearer resources at a transport 
gateway (e.g. RCEF for xDSL). 



7.5.13 Flow-Description AVP 



The Flow-Description AVP (AVP code 507) is of type IPFilterRule, and defines a packet filter for an IP flow with the 
following information: 

• Direction (in or out). 

• Source and destination IP address (possibly masked). 

• Protocol. 

• Source and destination port (list or ranges). 
The b type shall be used with the following restrictions: 

• Only the Action "permit" shall be used. 

• No "options" shall be used. 

• The invert modifier " !" for addresses shall not be used. 

• The keyword "assigned" shall not be used. 

The direction "in" refers to uplink IP flows, and the direction "out" refers to downlink IP flows. 
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7.5.14 Specific-Action AVP 

The Specific- Action AVP (AVP code 513) is of type Enumerated. 
The following event from TS 129 209 [7] is supported: 

• 1ND1CAT10N_0F_RELEASE_0F_BEARER (4): 

Within a RAR, this value shall be used when the delegated x-RACF reports to the delegating x-RACF 
the release of a bearer (e.g. RCEF policies being removed). In case of failure of a multicast request, the 
RAR message includes the address of the UE that requested the multicast flow and the flow description 
of the flow. 

Within a CCR, this value shall be used when the delegating x-RACF reports to the delegated x-RACF 
the release of a bearer (e.g. RCEF policies being removed). In case of failure of a multicast request, the 
CCR message includes the address of the UE that requested the multicast flow and the flow description 
of the flow. 

In addition, the present document defines two new events: 

• INDlCATION_OF_SUBSCRlBER_DETACHMENT (6): 

Within a RAR, this value shall be used when the delegated x-RACF reports to the delegating x-RACF 
that a subscriber has been detached. 

Within a CCR, this value shall be used when the delegating x-RACF reports to the delegated x-RACF 
that a subscriber has been detached. 

• INDICAT10N_0F_RESERVAT10N_EXP1RATI0N (7): 

Within a RAR, this value shall be used when the delegated x-RACF reports to the delegating x-RACF 
that a reservation is about to expire. 

Within a CCR, this value shall be used when the delegating x-RACF reports to the delegated x-RACF 
that a reservation is about to expire. 

Other events but the above-hsted ones defined by TS 129 209 [7] are not relevant at the Rr interface and are not 
supported. 

7.5.15 Globally-Unique-Address AVP 

The Globally-Unique-Address AVP (AVP code 300) is of type Grouped. 
AVP Format: 

Globally-Unique-Address ::= < AVP Header: 300 13019 > 
[Framed- IP-Address] 
[Framed- IPv6 -Prefix] 
[Address -Realm] 

7.5.16 Address-Realm AVP 

The Address-Realm AVP (AVP code 301) is of type OctetString and contains an address realm in the form of a FQDN. 

7.5.17 Logical-Access-ID AVP 

The Logical-Access-ID AVP (AVP code 302 13019) is of type OctetString. It is defined in ES 283 034 [4]. 

7.5.18 Framed-IP-Address AVP 

The Framed-IP-Address AVP (AVP Code 8) is of type OctetString and contains an IPv4 address of the type specified in 
the attribute value to be configured for the user. 
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7.5.19 Framed-IPv6-Prefix AVP 

The Framed-IPv6-Prefix AVP (AVP Code 97) is of type OctetString and contains the IPv6 prefix to be configured for 
the user. 
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